Answers.Body: <p>Relabel is a great plugin and the option to re-use fields without sacrificing semantics for the content editor can be very useful, especially if you (potentially) face creating <em>a lot</em> of similar fields (hundreds) in order to provide specific labels and instructions. I'm not aware of any technical or performance related issues with the plugin, but here's a couple of things worth considering before going all in:</p>
  
  <ul>
  <li>Your content model will be less flexible. For instance, if you use the same Rich Text field everywhere, you're not going to be able to have different settings for different types of content (perhaps entry type X needs a different Redactor config than entry type Y, or you need to disable/enable HTML purification for a specific piece of content – there's no way to make that happen if you use the same field for everything). This is especially troublesome if you only figure out you need different settings for different types of content <em>late in development</em> (or even after initial development has concluded), i.e. after adding a ton of content to the site. Of course, this applies to Craft even if you're not using Relabel, but personally I always lean towards creating two fields if there's even a slight chance I'm going to need different settings for different things.</li>
  <li>Your templates will be less semantic. Even if you add the labels "Hero text", "Body" and "Description" to a Rich Text field with the handle <code>richText</code> across your content in the CP, you'll still have to call <code>{{ entry.richText }}</code> everywhere in your templates. Losing the semantics and clarity of <code>entry.heroText</code>, <code>entry.body</code> and <code>entry.description</code> could make your code more confusing and harder to debug and/or read in the long run.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-07T13:24:19.170Z
Answers.LastActivityDate: 2016-05-07T13:29:50.983Z
Answers.LastEditDate: 2016-05-07T13:29:50.983Z
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Body: <p><a href="https://straightupcraft.com/craft-plugins/relabel" rel="nofollow">Relabel</a> certainly seems quite useful in being able to apply a more generic use to fields. The more I use it the more I see a use case for just creating a generic field with the same name as it's fieldtype which can be re-labeled and re-used in specific instances. <strong>Is anyone doing something similar and are there any potential issues to that approach?</strong> It seems to make things much more modular and re-usable.</p>
  
  <p>So, for instance you could create an instance of fields such as Plaintext called Plaintext, Richtext called Richtext, etc. Then just relabel them and provide specific instructions in an on-the-fly basis when required. That would help to cut down on the number of fields in use.</p>
  
Tags: <dry>
Title: Logistics of loose field naming and re-use with Relabel
ThreadText: # Logistics of loose field naming and re-use with Relabel
  
  (Asked by: username_0 on 2016-05-06)
  
  [Relabel](https://straightupcraft.com/craft-plugins/relabel) certainly seems quite useful in being able to apply a more generic use to fields. The more I use it the more I see a use case for just creating a generic field with the same name as it's fieldtype which can be re-labeled and re-used in specific instances. **Is anyone doing something similar and are there any potential issues to that approach?** It seems to make things much more modular and re-usable.
  
  So, for instance you could create an instance of fields such as Plaintext called Plaintext, Richtext called Richtext, etc. Then just relabel them and provide specific instructions in an on-the-fly basis when required. That would help to cut down on the number of fields in use.
  
  **Tags:** dry
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-05-07. Score: 1
  
  Relabel is a great plugin and the option to re-use fields without sacrificing semantics for the content editor can be very useful, especially if you (potentially) face creating *a lot* of similar fields (hundreds) in order to provide specific labels and instructions. I'm not aware of any technical or performance related issues with the plugin, but here's a couple of things worth considering before going all in:
  
  * Your content model will be less flexible. For instance, if you use the same Rich Text field everywhere, you're not going to be able to have different settings for different types of content (perhaps entry type X needs a different Redactor config than entry type Y, or you need to disable/enable HTML purification for a specific piece of content – there's no way to make that happen if you use the same field for everything). This is especially troublesome if you only figure out you need different settings for different types of content *late in development* (or even after initial development has concluded), i.e. after adding a ton of content to the site. Of course, this applies to Craft even if you're not using Relabel, but personally I always lean towards creating two fields if there's even a slight chance I'm going to need different settings for different things.
  * Your templates will be less semantic. Even if you add the labels "Hero text", "Body" and "Description" to a Rich Text field with the handle `richText` across your content in the CP, you'll still have to call `{{ entry.richText }}` everywhere in your templates. Losing the semantics and clarity of `entry.heroText`, `entry.body` and `entry.description` could make your code more confusing and harder to debug and/or read in the long run.
  
  
  ---
  
  