What are some unique content modeling cases in which you would find Global Fields particularly useful?


Userlevel 4

What are some unique content modeling cases in which you would find Global Fields particularly useful?


70 replies

Badge

Global fields would be handy for quite a few things, SEO, configurations, and classifications off the top of my head. 

Badge

A global field could be used for hero banners which are used across multiple content types. For example, desktop image, mobile image, title, subtitle, link.

Badge

Some unique content modeling cases in which I would find Global Fields particularly useful are: SEO, Taxonomy, and configs. Largely, Global Fields will be useful anywhere you can parse out a subset of content that will be used within multiple content types.

Badge

Maybe the organisations contact details?

Badge

A context in which I would find Global Fields particularly useful is when handling SEO, via keywords, descriptions, tags, etc

Badge

I wouldn’t say there is a particular use case where global fields are especially useful. All in all, any combination of fields which are reusable amongst different content types seems useful to me. Just to name some of them:

  • SEO on page level (as used in the course)
  • Assets considering SEO, e.g. images (the global field would be a combination of the image, an alt text and a title)
  • Address data (name, street, zip, city)
  • Contact data (phone, mail, fax,...)

 

Badge

I also find global fields useful for labelling, classification and configuration.

Badge

Surfacing metadata from external systems that content or portions of content might be sourced from. For example, if I’m integrating with a partner that doesn’t support a direct API connection, it might be useful to store metadata—such as an external id or source URL—for those entities.

Reusable fields you will need on multiple different locations, so that you can ensure these input fields are in sync over multiple content types. The example used in the exercise itself (SEO) was quite on point as an example. Other things I can think of are:

  • Set of booleans for configuration of a page; for example:
    • Should an external chatbot plugin be enabled on this page
    • Should an external feedback plugin be enabled on this page
  • Metadata (other than SEO); for example Google Analytics or any other analytics tool

There probably are enough other examples, which I can't think of now. But I presume that anytime you notice you reuse something over different locations, in multiple content types, it should ring a bell and you should consider using Global Fields.

This is good stuff.

Badge

Global fields would be great for something like SEO or a component that is universal to all pages, such as a hero banner.

Badge

Global field are useful when we need to share components between different pages of our website. For example:

SEO tags

Some boolean configuration

Headers or footers

Badge

I find global fields useful for SEO variables and special page rules and parameters (such as allowing/denying indexing, allowing/denying guest access, locking/unlocking comment areas, making pages visible/invisible, etc). This can be an interesting way of the dev team placing dynamic functionality that can be controlled directly by the content team.

We figured out that setting up Image, Video and iFrame references as Global fields is quite convenient as it allows to keep the configuration consistent for all components types.

Badge

What are some unique content modeling cases in which you would find Global Fields particularly useful?

As we can reuse the global fields across content types there are many cases where we can use them. But the most common one is the SEO fields as stated in course. Another can be some configuration settings which the developers can use like boolean fields. If there are any rules then we can configure them globally and have all pages access them.

Badge

SEO, Configurations

Badge

any time the same content, uniform, unchanged, needs to be on multiple web pages. no need to recreate per page when you have this info formatted and saved as a Global Field

Badge +1

Depends on the types of website content (such as retailing, education, research, consulting, etc.), there are various categories of common fields which may be necessary (such as a content publish/expiration date field which may trigger some backend cadence, a keyword/description field which may be useful for SEO, etc.) to add to each and every type. Those common fields would be Global fields. 

 

Badge

SEO is a good use for global fields. You could incorporate global metadata from other systems. 

 

Also the use of repeated, common fields among modules, saving time not recreating them every post. 

Badge

It could be useful when you have a reusable set of fields that could be used across different content types. The SEO and configuration fields are wonderful examples. Other examples could be:

  • Icon select field with a predefined set of icons
  • If you need to use phones in different content types, you could have the number, extension, and type fields inside the phone global field and reuse the set.

 

Badge

Global fields are particularly effective for all-page settings (SEO), or any other information that is used across multiple content types.

Badge

Global fields are great for anything repetitive, there’s so many ways they could be used. Anything from SEO, to email sign up blocks, banner ads. So useful!

Badge

It seems to be useful for storing supplementary information used across all/multiple content models, such as metadata or configuration.

One useful example of global fields is to create a taxonomy to be used within content types to categorize the content.

A more clear example is to create a field that can be reused by different content types, and can be updated (e.g.: adding fields) from a single place.

I’ve found that when you add such a global field, it instantly becomes mandatory in an entry, which is not great for my use case. The workaround I’ve found is to place my taxonomy select field inside a modular block inside a global field, but I would prefer if global fields could be set as optional instead.

Badge

Global fields are good for any content that needs to be used across many entries.

Badge

Reusable configuration settings or needed values that need to maintain a consistent structure through the entire Stack.

Reply