Meta Box

Thanks, the updated where to buy code did the trick. I figured there was probably an easier way to handle theat.

Regarding the selector. In you POST field type you have the option select field type as select, select Advanced (which I believe is the SELECT2 interface) Select tree, and so forth.

I would like to just extend those same options to the relationship designation. Cause as i said, the current form field requires 3 clicks to select the desired relationship. Select Advance might be 2 clicks but takes up less real estate and prevents selecting a relationship twice. and a checklist or radio list would be one click and maybe some scrolling.

Also your current system allows the same entries to be selected multiple times which is not good. Meaning you can have an Model 1: Related Model B, multiple times which I believe would create some repeated outputs or integrity problems.

In my opinion though, all relationship items should be within the custom field selection.

I created a mockup of how I believe my suggestions (and a few others) could be implemented. I strongly believe if you are able to get this database solution figured out and user friendly, you will gain a lot of new subscribers for all the developers who do not use WordPress due to the crazy data structure.

mockup

Add New Note to this Reply

So since you really did not address any of the concerns and point of confusion regarding the DOCS which was the point of this prompt, I will try to clarify. IE, I have read the docs, but I have questions regarding the docs. So linking back to the docs in which I have questions, is not the answer I need.

1. I am aware you use TEXT for everything.
I'm also aware WORDPRESS stores basically everything into the database and then compiles it into working code.

With that said, My FEATURE REQUEST is that you all think about improving usability within your plugin by having an advanced tab that allows people to change data structures. A column for data type, an input for size, a checkbox for nullable data and such. You know, like how php my Admin does it or any other database program.

IF no data is changed, then you default to TEXT as you have it. But as I said before, there are many fields that will have obvious data types, and a little thought on your part would save people the hassle and improve performance.

SWITCHes are always Boolean. numbers are INT

if someone set a limit of characters on a field, why not create a corresponding varchar or char? Again you can use TEXT default, but please provide a UI option for people to choose what works for their app without having to dive into the mysteries of WordPress custom code.

Your plugin has a bit more native options than ACF, so if you can make it more user friendly, you would surpass ACF in sales for the sole fact you have that native database and relationships to by pass WordPress's ugly way of data storage. I'm trying to help you make it more user friendly as right now, there are some confusing aspects.

1A This is where I am confused

After I create the table with

register_activation_hook( __FILE__, function() {
    MB_Custom_Table_API::create( 'my_custom_table', [
        'address' => 'TEXT NOT NULL',
        'phone'   => 'TEXT NOT NULL',
        'email'   => 'VARCHAR(20) NOT NULL',
    ], [ 'email' ] );
} )

<strong>

Do I then also need to link the table to the fields? Or is that step only if I create a table outside of WordPress? </strong>

And if I am linking the fields I created in the UI, to that custom table, is that where this "connecting custom fields to custom table" part comes into play? cause it sure seems like the code presented in the docs is creating the fields opposed to using the ones already made. I can understand if i need to map 'field_names=>'column_name' (though this should be automatic if name===column), but I'm not understanding why I need the other field information to create a link to a properly structured table if I already created the fields in the UI.

I need this to be as seamless as possible, cause if I transfer my whole project to wordpress with a fully normalized set up, this is what I would be working with. <a href="https://boss21784.imgur.com/all#3" rel="noopener" target="_blank">database</a>

Your plugin is helping me get there, but there's still some things I need to clarify and figure out how to make them work.

3. Im also aware of the relationship docs. That created table is fine for most cases. M:M with a polymorphic set up.

My first question was regarding 1:M, which is handled by the POST field, and stored as an array in the DB. While not ideal, I can live with it as long as i can reference the ID's

My problem however, is if I need to reference a field of that related post. How do I do this?

<strong>Sample: Equipment has vendors</strong> vendors has a URL to their website. So on the equipment page, i need to loop through the "where_to_buy" and then instead of using post_url, i need the vendor_url as the link. I'm not sure if its something within bricks builder giving me trouble, or if i'm coding it wrong, but I cannot get the link to display properly.

<?php $post_ids = rwmb_meta( 'where_to_buy' ); 

foreach ($post_ids as $post_id):
?>
<a>"><?= get_the_title( $post_id ); ?></a><br/>
<?php endforeach ?>

3A-- also regarding the ALT names, if these are stored in a serialized array, how would I reference them in search, so that my search would be Select post_title FROM POST or "alternative_name" FROM model.alt_name so that the same record would be displayed in search results. IE if i had this on a user table, I might want to search by the user name or a nick name, or perhaps a maiden name. My sample is from a hobby table in which a hobby could be known as several things. So those alternative names need to be searchable as if they were the post title itself

3B: Finally regarding the relationship inputs. That is also a bit confusing the way you have it set up.

First, please define reciprocal relationship or use a different wording within the plugin UI so people dont have to reference the docs or a dictionary to figure out what this is. Just add this same line " a relationship between items of the same type. If you choose this, make sure you set the settings for the "From" and "To" sides the same." And maybe add an example "IE. USER to USER relationship"

BUT SECOND, and most confusing is in which field I need to place my labels.

If i have my equipment to Vendors table in From/ To respectively,

If I'm picking the Equipment post type as a reference, I'd expect that the corresponding metabox, and column labels would be Equipment, yet its the opposite. (even if the equipment box gets added to the vendor edit screen, the labels should be consistent to avoid confusion.)

And perhaps your set up is technically right, but if i have to spend 5 minutes thinking about what input needs to go in which box to get the correct label, then it needs to be reworked.

Sample

Maybe instead of FROM: TO: You can use model 1, model 2. the models need to be referenced, and explained, or with a sample text that says, Title (1): Connection to model 2 (IE Vendor)

or under Metabox From settings, "What you see on the TO model" and To Settings: "What you see on the FROM MODEL"

It just needs to be made clearer somehow cause even trying to explain the issue here, I'm having to spend considerable time figuring out what goes where.

Finally - Another IMPROVEMENT REQUEST
If the selector could have an option to choose from the various select types your plugin offers, that would also improve things. Listing the vendors out in the default taxonomy view so its a one click selection opposed to 3, would be ideal, but the SELECT 2 Interface would also work better than the current method.

Anyway, sorry for the long posts. Just trying to improve usability and understand what I need to do to make my app work.

Add New Note to this Reply