Naming Conventions / Cleaning Up

• Porter

• October 9, 2018 at 8:17 am

Two-part question here, and I know it’s been asked to some extent over the years, so I’ll keep it short and sweet.

Naming conventions, need a bit more info than what I found searching for old topics. If I have “main features” and “sub features” for a Home page, with various duplicate field content such as Images, Summary, Link, etc, it makes sense to me to do something like:

main_feature_images
main_feature_links

sub_feature_images
sub_feature_links

Both have images, both are features, both belong to the same custom post type, or in this case, page. Is that method ideal? If not, what is?

For something like a custom post type, in my case, “game”, do / should I add a prefix of game? For fields such as this:

name
release_date
platforms
images
videos

I assume “images” from one post type wouldn’t conflict with “images” from a home page, or other post type – that being said, maybe adding game_ is ideal to avoid conflict with plugins? I’m about to refactor my code to finalize my naming conventions for a lot of fields, and would like to get it organized decently this time around.

Additionally, I found a lot of request for cleaning up old fields that aren’t used, but no definitive answer as to if it was added or not – is this a thing yet? If I use the export tool for my fields once they’re done on my local site, and import them to a new local / a production site, that would only copy over my selected / final names, right? This seems like it would essentially be “cleaning” out unused names, and be good moving forward as long as I always tested them locally before locking them in to my live version.

• John Huebner

• October 9, 2018 at 11:26 pm

There is no perfect answer for this. Field naming is open to opinion.

When I am creating fields I try to prefix them all with something to ensure uniqueness, but this is also based on the conditions.

If I am building a plugin, the all field names have what I hope is a unique prefix.

If I’m building a site that will only be used for one client, then this usually does not happen. In this case, when it is appropriate, I use a prefix that matches what the fields are for. For example, if I am building a product sections then all the fields will be prefixed with something like product_ or prod_ if I want to keep it short.

Custom fields must be unique for the WP object they are attached to. All of the fields for a single Post must be unique. Any fields for a single Term must be unique. All Options fields must be unique. The exception to this are sub fields of any type. sub fields are automatically prefixed with the parent’s (and grandparent’s, all ancestors’) field name. This makes them unique if the top level parent field is unique.

As far as changing field names. There is no way to safely change a field name and update all of the fields in all locations with the new name. Changing field names will cause the data to become disconnected. This is no different than any standard WP meta_key.