Use same channel field across channels

Question

I am trying to setup meta tags for my site specifically for Facebook sharing.

I have 4 different channels and I want to ideally use the same channel field for each of them so I can efficiently publish the "description" tag without complex {if} statements.

What is the best way to achieve this?

If I can't use the same channel field can I use something along the lines of {{channel_short_name}_summary}?

Any help appreciated.

N

{exp:channel:entries channel="projects|case_studies|articles|about" url_title="{segment_3}" status="open" disable="categories|category-fields|member-data|pagination"}
{exp:channel_images:images entry_id="{entry_id}" cover_only="yes"}

<meta property="og:title" content="{title}"/>
<meta property="og:image" content="{image:url:small}"/>
<meta property="og:site_name" content="mysite.com"/>
<meta property="og:description" content="{{channel_short_name}_summary}"/>
{/exp:channel_images:images} 
{/exp:channel:entries}

Answer 1

I try to always prefix custom fields with the channel name like so:

• projects_fieldname
• case_studies_fieldname
• articles_fieldname
• about_fieldname

Swap out "fieldname" for the actual custom field name of course.

Aside: I often start with the channel, then custom field type, then name. For example about_textarea_summary. There is a character limit so sometimes you have to be smart about abbreviation.

Then if you want to go the variable variable route you could make use of the channel short name variable like you described.

<meta property="og:description" content="{{channel_short_name}_summary}"/>

In your case you'd of course have 4 different custom fields named like:

• projects_summary
• case_studies_summary
• articles_summary
• about_summary

This method of course is going to run up against Parse Order as those variables are parsed during stage 5 as is the channel entries tags and there is no way of knowing which will come first.

This is why using something like Stash nowadays is so great. You can also use segment variables because those are parsed earlier.

For example if you used the same naming conventions for your channel custom fields as I described above and you have your channel short names set as the first segment of the url you could do the following:

<meta property="og:description" content="{{segment_1}_summary}"/>

One thing to note is in the case of your case_studies channel you might want to go with case-studies_summary for the custom field name if your URLs use dashes over underscores.

Answer 2

If all you need is one field per channel, you could possibly use the oft-overlooked Channel Description field.

Answer 3

Ok I am not expert but basically I do this sort of thing like this...basically a router embeds a model which embeds a view (layout). You don't necessarily need the router bit...but the model and view approach is really really great and avoids all sorts of parse order conundrums.

Router

I have a single router template as my index.html in each template group. This dissects the URL and then stash:embeds a model. Occasionally, above this, I have some stash sets to pull, for example, lists of categories I may use in the routing below. E.g.:

(top)

!-- Get the textures and the brands--}
{exp:stash:set parse_tags="yes" trim="yes" debug="yes"}
    {stash:textures}{exp:gwcode_categories cat_id="9" depth="3" style="linear" backspace="1"}{cat_url_title}|{/exp:gwcode_categories}{/stash:textures}
    {stash:brands}{exp:gwcode_categories cat_id="10" depth="3" style="linear" backspace="1"}{cat_url_title}|{/exp:gwcode_categories}{/stash:brands}
{/exp:stash:set}  
{!-- Join those together --}
{exp:stash:set parse_tags="yes" trim="yes" debug="yes"}
    {stash:sub_cats}{stash:brands}|{stash:textures}{/stash:sub_cats}
{/exp:stash:set}  

And then (just part of it)

(below the top, the actual url routing)

{exp:stash:parse parse_vars="yes" parse_depth="3"}
    {exp:switchee variable="{segment_2}" parse="inward" debug="yes"} 
        {!-- PAPERS MAIN INDEX --}
        {case value=""}
            {stash:embed:inkjet:model_index}
        {/case}


    {!-- PAPERS --}
    {case value="paper"}
        {switchee variable="{segment_3}" parse="inward" debug="yes"}
            {!-- PAPER INDEX -> REDIRECT TO GENERAL INDEX --}
            {case value=""}
                {stash:embed:inkjet:model_index_paper}
            {/case}
            {!-- SEARCHING BY BRAND OR SURFACE--}
            {case value="{stash:sub_cats}"}
                {stash:embed:inkjet:model_index_paper_brand_or_surface} 
            {/case}
            {!-- PAPER ENTRY --}
            {case default="yes"}
                {stash:embed:inkjet:model_product_paper}
            {/case}
        {/switchee}
    {/case}   {!-- seg2 = "paper" --}


'...etc

This model is basically a channel entries wrapped around a bunch of stash:sets. Indeed, it may also pull categories data or whatever. The beauty of it is you just pull all the data as stash set it as variable, you don't need to worry about parse or page order at all really.

MODEL

stash:embed:layouts:layout_product_options_inkjet_paper}


{exp:channel:entries 
    channel="product_inkjet_paper" 
    disable="{lv_disable_default}" 
    limit="1" 
    url_title="{segment_3}"
    require_entry="yes" 
    dynamic="no"}   

{exp:stash:set name='page_title'}{title}{/exp:stash:set}
{exp:stash:set name='page_h1'}{title}{/exp:stash:set}

{!-- BASIC PRODUCT & CHANNEL FIELDS --}
{sc_set_basic_entry_fields}
{exp:stash:set debug="yes"}
    {stash:product_unavailable}{cf_paper_unavailable}{/stash:product_unavailable}
    {stash:one_line_description}{cf_printer_one_line_descrip}{/stash:one_line_description}
    {stash:is_description}{cf_paper_is_descrip}{/stash:is_description}
    {stash:manufacturer_description}{cf_paper_manufacturers_descrip}{/stash:manufacturer_description}
{/exp:stash:set}


{!-- CATEGORY FIELDS --} 
    {exp:gwcode_categories entry_id="{entry_id}" excl_cat_id="10" excl_cat_id_children="yes" last_only="yes" style="linear" parse="inward"}
       {exp:stash:set debug="yes"}

            {stash:cat_url_title}{cat_url_title}{/stash:cat_url_title}
            {stash:cat_name}{cat_name}{/stash:cat_name}
            {stash:cat_id}{cat_id}{/stash:cat_id}
            {stash:cat_title}{cat_title}{/stash:cat_title}
        {/exp:stash:set}
    {/exp:gwcode_categories}

{sc_set_basic_entry_fields} - this is an early parsed low variable that just contains basic stash:sets of entry_id, channel_short_name etc.

The model embeds the layout, which is where we put this all together. I break mine up into modular little chunks, each stored as an early parse low variable (a snippet)

VIEW

    {lv_global_htmlhead}



    
        {lv_global_navigation}
    

{lv_page_header}

{!-- THE MAIN PAGE FIELDS --}
{exp:stash:parse parse_tags="yes"}

    {sc_product_brand_range_links}        
    {sc_product_images}
    {sc_product_availability_and_notes}
    {sc_product_add_to_cart_variations}

    ...etc

{/exp:stash:parse}

<div id="page_footer">
    {lv_global_footer}
</div>

{lv_space}

(Not this is not a fully finished example and I have cut various things for brevity).

Each sc_whatever is something very simple, and a self contained block, like:

    {exp:ce_img:pair src="{stash:master_image_url}" max="175" crop="no" allow_scale_larger="no" parse="inward"}
         
    {/exp:ce_img:pair}

So, and finally here's the point - the only thing that varies really, for each of your channels, is the model. It pulls from the different channels using their fieldnames, whatever they are, but it stashes the data into the same named stash variables - so that you only need one layout template to deal with the data coming from different channels. (You can take it a step further and do template inheritance as well - https://github.com/croxton/Stash/wiki/Template-inheritance - although I haven't implemented that yet myself).

You can see an alternate and better described version of this at http://pixelfear.com/blog/stash-workflow

Hope this helps! Obviously this is a non-trivial amount of complexity to solve this particular issue...but I am using it for a lot more than this of course. And conce you're on top of it - separating data retrieval from display in EE - I think it would be hard to go back to another approach as this so deftly avoids a whole host of issues and brings performance gains to boot...

Answer 4

Unfortunately you pretty much need to have the "same" field for each channel.

Prefixing the field names with channel short name is clever, or you could just output all of the variables in your loop. Nasty, but gets the job done, as any field name you call that doesn't exist, is simply ignored.

<meta property="og:description" content="{projects_summary}{case_studies_summary}{articles_summary}{about_summary}"/>

Answer 5

+1 for Stash for this (and almost everything!).

You can pull from all the channels usign whatever filed names you have used, and stash the data into stash variables the same names, and then inject these into re-usable template chunks. It's great!

Not only does it solve this annoying issue with fieldnames, it neatly gets around a whole host of parse order crap at the same time. Once you get it, it makes development a LOT more DRY and indeed simply easier.