Answers.Body: <p>Forgive me but after re-reading everyone's input, I lean towards Moto_Nomad relationships suggestion, mostly because it will make life as easy as possible for the content-administrator.</p>
  
  <p>In your latest comment you write:</p>
  
  <blockquote>
    <p>...but the issue is not about relating entries, but smaller bits of information, for which there is not a prescribed location.</p>
  </blockquote>
  
  <p><strong>Q: Could you give us an example of a 'smaller bit of information', please?</strong></p>
  
  <blockquote>
    <p>That is, there are bits of information which could be used nearly anywhere within the CMS (things like the <strong>event booking link</strong>, <strong>booking deadline</strong>, <strong>event start date</strong> etc etc)</p>
  </blockquote>
  
  <p>I'd suggest that the 'smaller bits of information' as well as the info you mention above, which are relevant to a Festival/Event should be stored within those (Event) Entries. </p>
  
  <p>Especially if these 'bits of info' are updated over time i.e. from from one event to the next.</p>
  
  <p>(I'll avoid going into an explanation of the <a href="https://craftcms.com/docs/entries-fields" rel="nofollow noreferrer">Entries field type</a>) </p>
  
  <p>;)</p>
  
  <blockquote>
    <p>The ideal solution would be that these bits of information are housed in one place in the CMS (probably will be a global), and can cleanly be pulled through to other areas of the CMS with a super user-friendly bit of syntax.</p>
  </blockquote>
  
  <p>Check out this thread: <a href="https://craftcms.stackexchange.com/questions/1268/is-it-possible-to-use-twig-in-a-rich-text-field">Is it possible to use Twig in a Rich Text Field?</a></p>
  
  <p>I realise the above is about the Front-End but thought it might be useful.</p>
  
  <p>Let us know how you get on, Mike :)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-28T14:20:02.503Z
Answers.Text: Thanks for the suggestions Matt! **Relationships.** Ideally we're looking for a solution for which the information can be pulled into any field, so a dedicated 'relationship' field unfortunately wouldn't fulfil that. **Smaller bits of information.** Things you've highlighted in bold in your second quote and also things like booking deadlines, current number of delegates, the minimum birth date to for serving etc. **Storing info in the main entries.** This may well be where we end up if this more complex route is not realistic! **Twig thread.** That's referenced in my 'Globals' section.
Answers.UserDisplayName: Mike Vaux
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-28T14:37:50.697Z
Answers.Text: Note to self, read AND click all links in a question :/
Answers.UserDisplayName: Matt P
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-28T10:57:31.993Z
Answers.LastActivityDate: 2016-06-28T10:57:31.993Z
Answers.LastEditDate: 2017-04-13T12:51:00.200Z
Answers.UserDisplayName: Matt P
Answers.Body: <pre><code>Reference Tags
  
  As these are limited to Plain Text field types, these are not an option.
  </code></pre>
  
  <p>Despite what the docs say, in my tests, Rich Text fields actually <em>are</em> parsed for reference tags. Not sure if/when this actually changed, but it seems to work now (Craft 2.6)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-08T15:17:22.240Z
Answers.LastActivityDate: 2016-08-08T15:17:22.240Z
Answers.UserDisplayName: Tim Kelty
Body: <p>We are trying to find the best solution for handling repeated content within existing Fields in the CMS.</p>
  
  <p>That is, there are bits of information which could be used nearly anywhere within existing fields in the CMS (e.g. inside a Plain Text field / Rich Text field etc) (things like the event booking link, booking deadline, event start date etc etc). The ideal solution would be that these bits of information are housed in one place in the CMS (probably will be a global), and can cleanly be pulled through to other areas of the CMS with a super user-friendly bit of syntax.</p>
  
  <p>-</p>
  
  <p>We've explored a few options, namely the following...</p>
  
  <p><strong>Reference Tags</strong></p>
  
  <p>As these are limited to Plain Text field types, these are not an option.</p>
  
  <p><strong>Globals</strong></p>
  
  <p>As per <a href="https://craftcms.stackexchange.com/questions/1268/is-it-possible-to-use-twig-in-a-rich-text-field)">this SE question</a>.</p>
  
  <p>This would involve having to add <code>include(template_from_string())</code> almost everywhere where a content is output from the CMS, which would be a pain and also the syntax might be a little confusing for the end user.</p>
  
  <p><strong>Create our own plugin</strong></p>
  
  <p>Whilst this might mean the syntax could be a bit more user friendly (e.g. something like <code>[main-event-dates]</code>, we would still have to pass every field output to the plugin (i.e. <code>craft.myPlugin.parseSyntax(entry.body)</code></p>
  
  <p><strong>Events</strong></p>
  
  <p>I'm just starting exploring <a href="https://craftcms.com/docs/plugins/hooks-and-events" rel="nofollow noreferrer">Hooks and Events</a>, and this looks like the best solution so far to me. From my understanding, the approach which would be most suitable for us would be something like this:</p>
  
  <p>myPluginPlugin.php</p>
  
  <pre><code>function init() {
      craft()-&gt;on('elements.onPopulateElement', function(Event $event) {
          craft()-&gt;myPlugin_main-&gt;parseSyntax($event);
      });
  }   
  </code></pre>
  
  <p>myPlugin_MainService.php</p>
  
  <pre><code>function parseSyntax($event) {
      // Parse the content of the fields, using something like the following
      $event-&gt;params['element']-&gt;getContent();
  }
  </code></pre>
  
  <p><em>Considerations with using the 'Events' method</em></p>
  
  <ul>
  <li>We would need to build in a mechanism of programatically clearing all template caches when one of those bits of central information is changed (as Craft will not be aware of which templates need their cache clearing)</li>
  <li>Is there a risk that this will be super php intensive to essentially loop though each field for each bit entry model / matrix block model etc etc?</li>
  </ul>
  
  <p>-</p>
  
  <p>Does anyone know of a better way to achieve what we are trying to achieve? Or feel strongly any way about any of the above?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-06-23T17:49:34.957Z
Comments.Text: My suspicion is that you're grossly overthinking it. Craft excels at reusing content, it seem like you're trying to reinvent the wheel here. Let me ask... is this a website for a **single, big event**, or for a **series of events**?
Comments.UserDisplayName: Lindsey D
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-06-27T22:07:45.747Z
Comments.Text: It seems like you are confused by "Hooks and Events" which is for internal CMS programing events... nothing to do with  "Events CONTENT(Lectures, Sporting Events, Concerts, etc)     I'd be looking at related entries https://craftcms.com/docs/relations.  Where you relate an entry for an concert event to a another blog type entry -or- you pull entries for upcoming event by date to the front page template, etc
Comments.UserDisplayName: Moto_Nomad
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-06-28T08:59:40.607Z
Comments.Text: @LindseyD : Hm, that was a suspicion but I'm not sure that we are to be honest. The website, which covers a whole organisation, exists to handle a great deal of information, both about the organisation, about the festival it runs (the main event), supplementary events, a blog, resources etc etc and the content is still growing (there will be an update over the next few weeks including a music section linked to the festival for example). For that reason, the client may well want to use information (e.g. about the festival) in multiple places within the CMS. Hope that gives a bit of context?
Comments.UserDisplayName: Mike Vaux
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-06-28T09:03:31.963Z
Comments.Text: @Moto_Nomad : No, I'm not confusing them, I understand that they are not in anyway linked to an "event" like a sporting event / concert etc. I think I made this clear in my question (forgive me if I didn't), but the issue is not about relating entries, but smaller bits of information, for which there is not a prescribed location.
Comments.UserDisplayName: Mike Vaux
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-06-29T16:50:21.907Z
Comments.Text: OK, So you want have site-wide type globals INSIDE rich text fields?  Sorry, the questions's title completely threw me off.
Comments.UserDisplayName: Moto_Nomad
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-06-30T08:16:29.067Z
Comments.Text: @Moto_Nomad Ok sorry about that - I've amended the wording slightly which hopefully is clearer now.
Comments.UserDisplayName: Mike Vaux
Tags: <plugins><events><globals>
Title: Best Method of Handling Repeated Content Within Existing Fields?
ThreadText: # Best Method of Handling Repeated Content Within Existing Fields?
  
  (Asked by: username_0 on 2016-06-23)
  
  We are trying to find the best solution for handling repeated content within existing Fields in the CMS.
  
  That is, there are bits of information which could be used nearly anywhere within existing fields in the CMS (e.g. inside a Plain Text field / Rich Text field etc) (things like the event booking link, booking deadline, event start date etc etc). The ideal solution would be that these bits of information are housed in one place in the CMS (probably will be a global), and can cleanly be pulled through to other areas of the CMS with a super user-friendly bit of syntax.
  
  -
  
  We've explored a few options, namely the following...
  
  **Reference Tags**
  
  As these are limited to Plain Text field types, these are not an option.
  
  **Globals**
  
  As per [this SE question](https://craftcms.stackexchange.com/questions/1268/is-it-possible-to-use-twig-in-a-rich-text-field)).
  
  This would involve having to add `include(template_from_string())` almost everywhere where a content is output from the CMS, which would be a pain and also the syntax might be a little confusing for the end user.
  
  **Create our own plugin**
  
  Whilst this might mean the syntax could be a bit more user friendly (e.g. something like `[main-event-dates]`, we would still have to pass every field output to the plugin (i.e. `craft.myPlugin.parseSyntax(entry.body)`
  
  **Events**
  
  I'm just starting exploring [Hooks and Events](https://craftcms.com/docs/plugins/hooks-and-events), and this looks like the best solution so far to me. From my understanding, the approach which would be most suitable for us would be something like this:
  
  myPluginPlugin.php
  
  ```
  function init() {
      craft()->on('elements.onPopulateElement', function(Event $event) {
          craft()->myPlugin_main->parseSyntax($event);
      });
  }   
  
  ```
  
  myPlugin\_MainService.php
  
  ```
  function parseSyntax($event) {
      // Parse the content of the fields, using something like the following
      $event->params['element']->getContent();
  }
  
  ```
  
  *Considerations with using the 'Events' method*
  
  * We would need to build in a mechanism of programatically clearing all template caches when one of those bits of central information is changed (as Craft will not be aware of which templates need their cache clearing)
  * Is there a risk that this will be super php intensive to essentially loop though each field for each bit entry model / matrix block model etc etc?
  
  -
  
  Does anyone know of a better way to achieve what we are trying to achieve? Or feel strongly any way about any of the above?
  
  **Tags:** plugins, events, globals
  
  > **Comments:**
  > **username_1**: My suspicion is that you're grossly overthinking it. Craft excels at reusing content, it seem like you're trying to reinvent the wheel here. Let me ask... is this a website for a **single, big event**, or for a **series of events**?  
  > **username_2**: It seems like you are confused by "Hooks and Events" which is for internal CMS programing events... nothing to do with  "Events CONTENT(Lectures, Sporting Events, Concerts, etc)     I'd be looking at related entries https://craftcms.com/docs/relations.  Where you relate an entry for an concert event to a another blog type entry -or- you pull entries for upcoming event by date to the front page template, etc  
  > **username_0**: @username_1 : Hm, that was a suspicion but I'm not sure that we are to be honest. The website, which covers a whole organisation, exists to handle a great deal of information, both about the organisation, about the festival it runs (the main event), supplementary events, a blog, resources etc etc and the content is still growing (there will be an update over the next few weeks including a music section linked to the festival for example). For that reason, the client may well want to use information (e.g. about the festival) in multiple places within the CMS. Hope that gives a bit of context?  
  > **username_0**: @username_2 : No, I'm not confusing them, I understand that they are not in anyway linked to an "event" like a sporting event / concert etc. I think I made this clear in my question (forgive me if I didn't), but the issue is not about relating entries, but smaller bits of information, for which there is not a prescribed location.  
  > **username_2**: OK, So you want have site-wide type globals INSIDE rich text fields?  Sorry, the questions's title completely threw me off.  
  > **username_0**: @username_2 Ok sorry about that - I've amended the wording slightly which hopefully is clearer now.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2016-06-28. Score: 3
  
  Forgive me but after re-reading everyone's input, I lean towards Moto\_Nomad relationships suggestion, mostly because it will make life as easy as possible for the content-administrator.
  
  In your latest comment you write:
  
  > ...but the issue is not about relating entries, but smaller bits of information, for which there is not a prescribed location.
  
  **Q: Could you give us an example of a 'smaller bit of information', please?**
  
  > That is, there are bits of information which could be used nearly anywhere within the CMS (things like the **event booking link**, **booking deadline**, **event start date** etc etc)
  
  I'd suggest that the 'smaller bits of information' as well as the info you mention above, which are relevant to a Festival/Event should be stored within those (Event) Entries.
  
  Especially if these 'bits of info' are updated over time i.e. from from one event to the next.
  
  (I'll avoid going into an explanation of the [Entries field type](https://craftcms.com/docs/entries-fields))
  
  ;)
  
  > The ideal solution would be that these bits of information are housed in one place in the CMS (probably will be a global), and can cleanly be pulled through to other areas of the CMS with a super user-friendly bit of syntax.
  
  Check out this thread: [Is it possible to use Twig in a Rich Text Field?](https://craftcms.stackexchange.com/questions/1268/is-it-possible-to-use-twig-in-a-rich-text-field)
  
  I realise the above is about the Front-End but thought it might be useful.
  
  Let us know how you get on, username_0 :)
  
  > **Comments:**
  > **username_0**: Thanks for the suggestions username_3! **Relationships.** Ideally we're looking for a solution for which the information can be pulled into any field, so a dedicated 'relationship' field unfortunately wouldn't fulfil that. **Smaller bits of information.** Things you've highlighted in bold in your second quote and also things like booking deadlines, current number of delegates, the minimum birth date to for serving etc. **Storing info in the main entries.** This may well be where we end up if this more complex route is not realistic! **Twig thread.** That's referenced in my 'Globals' section.  
  > **username_3**: Note to self, read AND click all links in a question :/  
  
  ---
  
  ### Answer by username_4 on 2016-08-08. Score: 3
  
  ```
  Reference Tags
  
  As these are limited to Plain Text field types, these are not an option.
  
  ```
  
  Despite what the docs say, in my tests, Rich Text fields actually *are* parsed for reference tags. Not sure if/when this actually changed, but it seems to work now (Craft 2.6)
  
  
  ---
  
  