{"id":4226,"date":"2016-06-01T12:31:11","date_gmt":"2016-06-01T12:31:11","guid":{"rendered":"http:\/\/www.garysieling.com\/blog\/?p=4226"},"modified":"2016-06-01T12:31:11","modified_gmt":"2016-06-01T12:31:11","slug":"wordpress-add-custom-type-custom-fields","status":"publish","type":"post","link":"https:\/\/www.garysieling.com\/blog\/wordpress-add-custom-type-custom-fields\/","title":{"rendered":"WordPress: Add a custom type with custom fields"},"content":{"rendered":"

If you’ve used any system that allows for custom fields \/ custom entities, you may find the WordPress system quite alien (e.g.: compare to SalesForce, Documentum, SharePoint etc).<\/p>\n

Like most tools, the WordPress customization model is typically a mix of configuration, code, and plugins, but since you can edit any code, anywhere in the system, you have to be a little careful (there is no notion of “versioning” the database, that I can see, for instance, so how to do migrations is an open question). <\/p>\n

Typically any piece of code you’d write yourself (e.g. adding a custom type) can be extracted and made into a plugin. Thus, part of customizing WordPress is a trade-off between deciding what to customize yourself and what to delegate to existing plugins.<\/p>\n

For adding a custom type, for instance, it’s pretty easy to just drop in some code:<\/p>\n

\n\nadd_action( 'init', 'create_post_type' );\nfunction create_post_type() {\n  register_post_type( 'error_message',\n    array(\n      'labels' => array(\n        'name' => __( 'Errors' ),\n        'singular_name' => __( 'Error' )\n      ),\n      'public' => true,\n      'has_archive' => true,\n    )\n  );\n}\n<\/pre>\n
This does start to show where some of the pain is going to come in – every attribute we add has to have labels for every action, which isn’t much fun to do.<\/p>\n
You can add custom fields as key-value stores, but they are hard to maintain and don’t support any complex value assistance behaviors.<\/p>\n
Consequently, the best thing to do is to install a plugin (“Advanced Custom Fields”) that manages this for you.<\/p>\n
Here, I’ve set up a custom field group for a section of my blog (“error messages from popular javascript libraries”). In my setup, each custom field is an attribute of an error message:
\n<\/p>\n
When you set this up, you have a fair amount of configuration options – you can make it a preset list of values, and make it conditional upon other fields:
\n<\/p>\n
The fields show up on the “new post” screen the way you’d expect:
\n<\/p>\n
Now that you’ve done this, you have custom fields. In future posts I’m going to investigate how to handle migrating changes (as an application grows), moving data from server to server, and other issues involved maintaining such a site.<\/p>\n","protected":false},"excerpt":{"rendered":"
Understanding the Wordpress model for custom fields<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[12],"tags":[601],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t