What’s in a Name? How should I name my Pods and Fields?

It’s actually a naming restriction from WordPress. Within your site, you can’t have names for Custom Post Types that conflict with either existing WordPress objects (user, post, page, media, etc) or existing Post Types. Within each post type, you can have duplicate field names across post types, because key/value pair in Post Meta is actually ‘keyed’ by the Post name or WP object. However, you can’t have duplicate field names within the same post type.

From a semantic viewpoint, I would suggest two different naming schemes. You have the field name the user sees (the simple field name next to the input field) and then you have that ‘programmatic’ field name like post_name, event_name, etc. I’d think about your end user/ux when naming the visual field name, but think about yourself and keeping things organized and consistent when naming fields for pulling them into templates or relationships or queries.

I tend to do this for all relationship fields: I start them with related_ or rel_ and then the name of the pod on the OTHER side of the equation. So for an author of a book, when I have a Pod called ‘authors’ (and yes, I name all my pods in ‘plurals’ so the slug in the SEO is plural), I would add the Author relationship field in Books as related_author or related_authors (if I made it a multiple field). In reverse in the Authors Pod, I would name the books relationship as related_books.

If you’re planning on pulling content into multiple templates that includes information from multiple Pods, you may want to prefix your fields with the Pod name, but it’s not necessary, but things like Event_Name, I tend to name that way. However, also remember the Title, post_title is available to all your Pods. No need to add a field for Event Name when Post Title in Events _is_ your Event Name.