How do you name your fields?!

[lenoir]

Hi,

I've been using PW on so many websites to this day, can't count them. Still, I'm always looking for a better way to name my fields. A typical problem is when I need multiple textfields on one template.

I sometime contextualize them (i.e. "lead", "maintext", "detailinformation", etc.) or use "textfield_1", "textfield_2", etc., and I even tried to differentiate them by their type or max characters ("textfield_formatted", "textfield_unformatted", or "textfield_500", …) 

So my question is… What solution have you found to this issue?? ?

[wbmnfktr]

I wrote something about that a while back. Not much has changed since then. 
Yet I still sometimes find myself in this question loop about naming fields, templates and such. 

 

[szabesz]

I do not think that a naming convention that fits all needs exits. Still, I mostly find useful using these "rules":

• "Thinking in reverse", something like French, where adjectives/describing words are usually placed after the noun:
  • text_head, text_subhead, text_body
• When using date/time: it is yyyy_MM_dd-HH_mm_ss or similar what I use. The important thing here is the order, so when alphabetically listed we also get chronological order.
• I try to avoid sequential numbering (text_1, text_2, etc) as they are meaningless.
• Adjectives/describing words should be semantic, whereby a name of something indicates its intention, purpose or relation to other objects and not its properties which might change:
  • text_h1 instead of text_bigred, for example
• When dealing with composit "objects/things" I often stick to the basic idea of BEM but I am not following it strictly.
• If lots of multiple of the same fields are needed for a template, I simply pick the most appropriate looking Pro field(s). I know this does not help those who do not have them, but if a project is big enough to warrant for such needs then the Pro fields are probably worth it, especially a DEV license is not that expensive at all, I think.

Edited March 17, 2022 by szabesz
point 1 above was fixed to mean what I actually wanted to...

[aagd]

For larger sites I mostly use generic, numbered fieldnames like text_ml_01 (ml for multilanguage) which I might generate via API. Then in the templates I change the labels to something more meaningful and via AutoTemplateStubs I copy the complete field info with labels into the php templates, looks sth. like:

/**
 * Template: basic-page (Basic)
 *
 * @property string $title Titel
 * @property string $text_ml_01 Headline
 * @property string $textarea_ml_01 Intro
 * @property string $body_01 Content
 * @property string $text_ml_02 CTA Button Label
 * @property mixed $url_ml_01 CTA Button URL
 * @property Pagefiles $files_ml_01 Linked Files
*/

For smaller sites I prefer more custom fieldnames.

[Robin S]

I use generic words and numbers for field names, e.g. text_1, textarea_1. I really wish I didn't have to do this and could use descriptive names for fields, but the problem is that I almost always want to reuse fields for different purposes on different templates. So while a name like "city" is more meaningful than "text_1", I think it's much more confusing to call $page->city in some template when that field is actually holding a person's job title or something totally unrelated to "city".

What I'd like is for PW to support field aliases, so that in the context of the "store" template I can give text_1 the alias of "city" and in the "employee" template I can give text_1 the alias of "job_title". Field aliases would need to be unique and in practice you could refer to a field by any of its aliases in any place in your code.

I have an open request for this: https://github.com/processwire/processwire-requests/issues/154
Ryan seemed supportive at the time but it hasn't progressed anywhere since 2018. If anyone else would like this feature please "vote" for it with a thumbs-up at GitHub.

I've also created a module that would allow aliases to be used but it can't be released due to issues with FileCompiler: https://github.com/processwire/processwire-issues/issues/882

[bernhard]

I guess nobody wants to hear that, because it seems to be too nerdy to create fields via code, but this is just another example why I love my setup so much. Thank's for reminding me of those days where I was struggling myself with those topics ? 

For those interested in an advanced approach of organising PW projects and keeping your setup clean I'll try to explain what I do for all my projects now. And that's another benefit: I always do the same. On every project. For every field. So every project works the same and I instantly know what's going on even if I haven't worked on the project for a longer time.

For me these two things were crucial:

1. Custom Page Classes
2. (optional) RockMigrations
3. (optional) RockMatrix or RepeaterMatrix

If you haven't used custom page classes be sure to check them out: https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes

That would actually take too long to explain... But I've shown some of the above mentioned techniques that might also be of interest for readers of this topic in the linked issue (https://github.com/processwire/processwire-requests/issues/154)

The sort version which might be an idea for you guys having troubles with field names: You could create a custom class that is loaded in _init.php where you define your fieldnames as class constants:

<?php
// site/_init.php
class MyProject {
  const field_body = 'body';

  const field_teaser = 'body1';
  const field_summary = 'body1';

  const field_cover = 'blog_cover_image';
}

Now you can access your fields in your templates like this:

<?php
// template newsitem
echo "<h1>{$page->title}</h1>";
echo "<div>".$page->get(MyProject::field_teaser)."</div>";

<?php
// template basic-page
echo "<h1>{$page->title}</h1>";
echo "<div>".$page->get(MyProject::field_summary)."</div>";

Note that we are reusing the field "body1" and referring to it as "field_teaser" in newsitem and as "field_summary" in basic-page.

Personally I don't do any reusing of fields any more but that's a different topic and relates to RockMatrix + RockMigrations. Hope the ideas where useful for someone nonetheless.

[lenoir]

Wow. These are great inputs! I'll have to look into them more closely, since they are some new concepts to me. I only feel stupid I haven't asked the community sooner ?