Meta Box

Hi Peter,

That is not same setup I have.

Here is the layout I have. Attached in the zip file are:
1. The custom post-type (tools)
2. The group fields (Company/User)

Note I'm using the custom table option to store my data. Note if you try to save a user and company the company data gets saved to the users data when using the wordpress forms.

https://www.dropbox.com/scl/fi/zhrclhuhsmptqhqk859bo/post-and-group-json.zip?rlkey=q17p5e5n4b4o536laqln7so2c&dl=0

One other point I need to mention. Within all my custom field groups I use the id 'addresses' for both my users and by company custom groups and table column names. If I change one of them to say 'addresses-1' then the rwmb_meta functions works.

This indicates that rwmb_meta can only work with one unique id, while the API works differently. If this is the underlying architecture, I assume that is fine, However it doesn't seem very consistent with the fact that you could pass in a custom table to the function but the function is really tightly coupled with the uniqueness of the ID and not the uniqueness of the table column of the args passed in, also the fact that the API works different than the rwmb_meta, seems a little awkward. Please let me know if this is an intended use of the function or if it's a possible bug.

Thanks

Hi,

I figured this out. If I just use the \MetaBox\CustomTable\API::get call then I can get back what I need and the code stack looks to be lighter than rwmb_meta. Do you have any plans to enhance the API with calls like?

\MetaBox\CustomTable\API::getAll
\MetaBox\CustomTable\API::getByIDs(array IDs)

Thanks for your time!

Hi Anh,

Thanks for the feedback!

Actually I just installed the plugin about 4-5 days ago, so I have not had a chance to upgrade yet. However I did use the toolset migrator to migrate the settings. So I'm assuming that would be equivalent to a type getting "registered" incorrectly? Below is a small snippet from the JSON export. I'm *assuming* that some of this data is probably incorrect?

"register_meta_box_cb": "",
"permalink_epmask": "EP_PERMALINK",
"update": false,
"_builtin": false,
"_toolset_edit_last": 1696873299,
"_wpcf_author_id": 2,
"wpcf-post-type": "tool",
"icon": "dashicons-database",
"editor": "block",
"custom_fields": {
	"wpcf-ref-status": true,
	"wpcf-ref-platform": true,
	"wpcf-ref-admin-link": true
},
"custom-field-group": {
	"6": true,
	"1654": true,
	"1695": true,
	"1864": true
},

I see the entry for "wpcf-post-type" in the wp_options table as a serialized array. Am I able to just update the values in the array (if so which ones)? I know how the serialized arrays work with string key lengths so I can adjust accordingly without breaking things, or is it safer/easier to just delete the post type using the MB Builder and re-create it without loosing any data.

Thanks again for your time!

Hi Peter,

Thanks for the feedback! I tried using the code that the plugin generates in my functions.php but the code it generates is full of issues. For example some of the args generated are:

'editor'                           => block,
'custom_fields'                    => [object Object],
'custom-field-group'               => [object Object],

Obviously none of those values are valid PHP types. Also why would the rest of the application work fine without adding that code to the functions.php?

This seems more like a PHP version issue. I'm not having the issue in PHP 7. It seems as though other plugins have faced similar issues.

I'm not really sure if the issue is related to the MB Custom Post Type extension, I just thought that might be the closest category I could correlate the issue to. Is it possible to have someone on the dev team take a quick peek at this to see if its a scenario where PHP 8 is the underlying cause?

Thanks~