Settling on a Standard Custom Field Naming Schema

WordPress themes & plu­g­ins are able to do some amaz­ing things. They can spice up your home page with ran­dom fea­tured images, pro­vide a myr­iad of caching tech­niques to improve user expe­ri­ence, or — and this is in just about everybody’s top 5 — soup up your site’s search engine optimization.

On the sim­ple side, a search engine opti­miza­tion plu­gin would add a meta box to the WordPress “Add New Post” screen. This box, which is basi­cally a pretty GUI for cus­tom fields, would allow users to add search engine treats such as a descrip­tion, key­words, and some­times even a post title specif­i­cally for the title tag.

The actual cus­tom fields being saved into your post’s meta, though, may go by vary­ing names. Again, on the sim­ple side, a plu­gin might save a search engine descrip­tion for a post into a cus­tom field with a key (name) of “descrip­tion.” The key­words would be saved into “key­words,” title into “title,” and so on.

But what we see in the wild among search engine plu­g­ins or themes with opti­miza­tion fea­tures build in is diver­sity. The sim­ple names may be used for some (or even many), but what of addons which use pro­pri­ety nam­ing schemes?

Let’s use the fic­tional Theme X as an exam­ple. You start your blog with it, you post for years, and you even­tu­ally amass a library of thou­sands of posts, all with search engine data saved using Theme X’s cus­tom field nam­ing schema: x_​description, x_​title, x_​keywords, et al.

But then some­thing awe­some hap­pens, and a search engine plu­gin named Plugin Y is released which promises to take your site into the next level of Search Engine Nirvana. You believe the hype to be jus­ti­fied, and you install the plugin.

After a few weeks, though, you start to notice that your older posts don’t seem to be per­form­ing as well in the search engines. After some inves­ti­ga­tion, you notice that your descrip­tions, key­words, and titles entered using Theme X’s sys­tem are no longer being used. Instead, Plugin Y forces its val­ues, and of course any post pub­lished prior to installing Plugin Y would have noth­ing to output.

So what do you do? Some may start the tedious task of man­u­ally reen­ter­ing the data using Plugin Y’s meta box. Others may look for a bit of data­base code to con­vert the old cus­tom field keys to the new ones used by Plugin Y (actu­ally, this is pretty easy to do).

But really, this sit­u­a­tion shouldn’t have to come up in the first place. Users shouldn’t be expected to have to play Compatibility Warden between plu­g­ins & themes, espe­cially on some­thing as sim­ple, not to men­tion impor­tant, as search engine optimization.

So what I would like to sug­gest to the WordPress com­mu­nity — and if you like this idea, run with it! — is to estab­lish some open stan­dards for plu­gin & theme authors, start­ing with cus­tom field nam­ing con­ven­tions for search engine meta.

Everyone’s job would be eas­ier if every devel­oper used “descrip­tion” for descrip­tion fields, and devel­op­ers would no longer find it nec­es­sary to either build in com­pat­i­bil­ity with other themes or plu­g­ins (which could be a nev­erend­ing task as oth­ers are devel­oped & popularized).

Compatibility, effi­ciency… and most impor­tantly no sur­prises for users who switch from one sys­tem to another.

Tagged as: WordPress