Reusable metabox backend and frontend

Question

I am trying to create a more transferrable/automated custom post type that would act as a error ticketing system (I know there are many out there, but I want one that is completely customised).

The CPT I have is called ticket with two taxonomies ticket_stage and ticket_application.

I also have the meta fields:

• closed - checkbox
• priority - select
• computer - select
• status - select
• submitter_name - input field (automated via logged in user)
• submitter_email - input field (automated via logged in user)

From the backend, it is easy to create a ticket, and assign all the right fields.

From the frontend, I am only able to pass the title, date, ticket_stage,ticket_application,post_bodyvia thewp_insert_post()`

I am able to manually create the meta fields and pass them, but I wanted to know if it was possible to loop the possible values in case there are future additions (say computer fields are removed or added). I tried searching for ways to loop meta fields, but without a post id, or anything written to the database for a post it is not know.

The only way I have been able to do it, but not sure if it is safe or not is this way:

During the creation of the meta fields, following this tutorial http://code.tutsplus.com/articles/reusable-custom-meta-boxes-part-1-intro-and-basic-fields--wp-23259 when you get to switching the fields switch($field['type']), I duplicate the entire function, give it a new name, an rearrange the fields. Then on the frontend page, I call the new function and pass them through a form.

Is that way safe, or recommended? Is there a better way to call metabox fields without manually writing out each key and updating when new keys are added?

I tried looking into using only taxonomies, and replacing certain taxes with radio buttons or select dropdowns, only to see codes that replaced all the taxes instead of individual ones.

The main reason to make them taxes, was so I could get the menu item for them, which I again couldn't find in any documentation.

Answer 1

I've handled this in a couple different ways.

1) You can manage the list of items in a settings page. You could add a simple comma delimited list of Computers, and pull them to the front end with get_options('computers'). If you want to build that into a dropdown you could do something like:

$list = get_options('computers');
$list_a = explode(',', $list);
echo "<select>";
foreach ($list_a as $item) {
    echo "<option value='$item'>$item</option>";
}
echo "</select>";

This will allow you to control the list separate from what is actually stored in post meta. That way you can add or remove items from the list of options without worrying about what was previously done.

2) Another option is to create some utility arrays in your code. I do this with things that are fairly static like US states, or Countries. I create a file and include it into my main plugin or functions file and reference it from there. You might have:

function get_computers() {
    return $computers = array(
    'acer' => 'Acer'
    ,'mac' => 'Mac'
    ,'lenovo' => 'Lenovo'
    );
}

You'd loop out these options in a similar way to my first example. You're just storing data in code instead of the database.

Finally, I think you're on the right track with using custom taxonomies where possible. A taxonomy called Computers might be easier to manage than either option above especially if you want a non-programmer to be managing it. You'd be able to get access to those with the get_terms() function.

You might also consider adding some custom post statuses. Instead of closing your ticket with a checkbox, you might add a post status called 'Closed'.

Get more info here: https://codex.wordpress.org/Function_Reference/register_post_status

Anyway, I hope that helps. For what you're doing, I would also recommend a helper like piklist. It would make the creation of all of the metaboxes, settings pages and fields a lot easier.