Got it! The problem is that on some of the post types you’re setting capability_type as an array. As is standard with register_post_type, it either has to be a string or an array with pre-defined indexes. From the looks of it, if you just change, for example, array('invoice') to simply 'invoice', that should fix the issue. But that depends on what you’re trying to do.

Hi @vayu!

Thanks! That helps!

Are you registering any custom post types via the piklist_post_types hook? If so could you show me the code for that? Either you’ve found a bug or there’s a simple misconfiguration.

Hi @vayu!

Most times in these situations it’s something using Piklist that’s misconfigured that’s causing the issue. Using the piklist function incorrectly, on accident, for example, can raise an error that looks like it’s Piklist having an issue.

In any case, could you please provide a stack trace to try and isolate the culprit line of code?

Hi @stham!

You would probably want to use the register_activation_hook instead of admin_init, otherwise you’ll be updating the settings every time the admin-side loads. Also, check to make sure there isn’t an existing value or you’ll overwrite what they’ve done if the plugin is deactivated and reactivated.

That said, using update_option should work just fine. Just make sure you’re using the right options key and saving in the format Piklist is expecting. I’d enter the values through the field, save it, then check out the wp_options table to see how Piklist is saving it out. It may either be a single, serialized row, or multiple rows per value (depending on whether it’s a group or not).

That should work. Piklist isn’t doing anything magical beyond the normal use of get_option and update_option.

The difference between admin-side and front-end forms is that in the back-end the scope of the fields are derived from the context. For example if a field is on the post edit page, the fields assume they should save as the meta of that post. On the front end there’s no screen context, so it’s up to you to define both the scope and the object (if there is one).

Try setting 'scope' => 'post'.

Interesting, so, to be clear, low priority fields aren’t saving for the default post type? Are you using the latest trunk version of Piklist? I just tried to reproduce this locally and am unable to; it’s saving and updating just fine.

You actually don’t need a ‘field’ value at all for relate fields. The field is only used to provide a key for custom meta fields.

Hi @mcmaster!

Interesting use-case. I’m curious, and not to dodge the issue, but why do you want the post type to support ‘custom-fields’ if you’re using Piklist to generate custom fields? The two seem to somewhat bleed into each other.