Custom Fields
Re-Envisioned
Support MB Settings Page Saving settings page data to custom table?

This topic contains 4 replies, has 2 voices, and was last updated by  GarySmith 4 months, 1 week ago.

  • Creator
    Topic
  • #15322
    Resolved
    GarySmith
    Participant

    The settings page doc doesn’t give any additional details regarding the option_name argument. Either you create it or it will use the ID. I am not sure if this affects the ability to save meta field data for a settings page into a custom table. The field group itself allows defining the storage type for a custom table.

    I noticed upon trying to save it creates an empty serialized array with the option_name in wp_options instead of saving to the custom table. I wondered if perhaps it was because I’ve included the wp table prefix in the table creation and needed to define that in the table name identifier of the meta_boxes array but I created a table without the wp prefix and it also doesn’t get data saved to it from the settings page.

    I was trying to use a cloneable group with the new feature clone as multiple so just for posterity sake I tested a fieldset and it also does not save the data to the custom table so I’m thinking either the settings page does not have support for saving to a custom table or the settings page needs some special arguments that aren’t defined in the documentation.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Author
    Replies
  • #15326

    Anh Tran
    Keymaster

    Hi Gary,

    Thanks for a great question. The settings page doesn’t support for saving to a custom table yet. The problem (technically) is the storage set for a setting page is fixed to use only options table.

    Besides, the custom table also maps fields with an entry (post, term or user) via its ID. In case of the settings page, there’s no such an ID. Thus, breaking the structure of the custom table.

    I’m curious why do you want to save settings to custom table? I don’t see any benefit using it over standard options table.

    #15329

    GarySmith
    Participant

    I’m re-building a premium plugin I built years and years ago as a premium theme (so old it was built on roots, long before there was ever a Sage theme). I have custom tables for global options. I use the term “settings page” as merely a place in the back-end to allow the user to define whatever options (I know WordPress wants to do away with settings pages in favor of the customizer but I think thats short-sighted and will never be adopted by most developers who want a back-end interface to manage options.). In this case its for creating unique URL combinations for affiliate links. (eg: https://$userid.myaffiliateprogram.com/) where the $userid gets replaced by whichever user it is, so its dynamic.

    Now I could just save these as options in serialized array but there is no limit to the amount of these links being created and they need to be queried and this is just one example. I have another custom table that creates user relationships (affiliate tiers). This could be saved as user_meta but that isn’t query friendly when we want multiple levels. (User 5 is Parent to User 3 who is Parent to User 10 etc… ) But from what you’re referring to Settings page also wouldn’t support saving to user_meta so thats a moot point.

    I want to use ACF Pro or MetaBoxes frameworks but I’d love to do so completely. If I have to go about and create a proprietary back-end page to associate all the custom stuff I need there doesn’t seem much benefit in re-building anyway.

    There may be more intelligent ways to accomplish what I want but obviously I’m not aware of them, I can only develop with the skills I have and I don’t think the options table and serialized arrays is a good place to build items that need to be queried somewhat extensively, though I could be wrong.

    #15334

    Anh Tran
    Keymaster

    I think the main problem with your settings is the unknown (probably huge) number of settings. There must be some way to resolve it beyond the custom table or options table. Because both solutions probably don’t work well with this kind of data structure (options table uses serialized array, while custom table requires fixed columns).

    I’m not sure about how you save data. IMHO I’d suggest reworking on the data structure first, then choose a way to store data.

    If you need any help from my side, I’m happy to do so.

    #15335

    GarySmith
    Participant

    I’m not sure any other way to do it really. If the Affiliate Link information was isolated to its own option as a serialized array, perhaps that wouldn’t be so bad, the purpose of this is to display the link dynamically. But bundling it with all other settings / options I think would complicate performing the lookup for the link structure we need when getting the ID.

    A user will fill out a field (to replace $userid) and all his children users will see his ID in this link so essentially his affiliate link shows for all people signing up under him. So it might be https://affiliateprogram.com/?id=garysmith.

    Using the serialized option for saving these link formats we could treat each array entry as an ID and render that via shortcode. [aff_link id=”1″]. This just lets us know to show the link https://affiliateprogram.com/?id=$userid. But we want to dynamically replace $userid with the current user’s parents information so he could get credit for sign-ups or fallback to use the default value which would be saved in the array for each link option (Name of Link, Link, Default).

    To do this we need to save the Option Array ID in the User Meta with whatever value should replace $userid. This could also be serialized where the data is $optionlinkid, $userid in the user_meta I suppose and for however many custom links there are, this could be saved in that format.

    To render this out dynamically for current user we use the ID of the shortcode to correspond to the entry in the options array. That lets us get the link format. Then we check the current user’s ID to find in his user_meta his parent user’s ID. Then we check the parent user ID user_meta for the serialized value where the option ID and the Name for replacing $userid value coems from. Finally we can render the link with the parent user’s saved information to the current user.

    Reading that all back sounds like its as efficient (or inefficient) as if we saved into a custom DB, but the look-up of the option Id might be faster since WP options are cached. It really only works if this option is separate for all other settings options.


    That being said, I can create a field in MetaBoxes to be readonly, can I populate that field with information from the DB. If I wanted to create a numbered ID field for example since I noticed on cloning / repeated elements there is no ID visible. In this example here, each of the options in the array needs an ID for us to confer to the user how to call it in shortcode so I would want to render an ID based on the entries this array has in it.

Viewing 4 replies - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.