Custom field data and custom Rest API fields

  • creativiii

    (@creativiii)


    5 years ago

    Hi all,

    I’ve been trying to expand my WordPress installation beyond just blogs and pages by creating a custom post type. The end-goal is to have a separate Rest API endpoint with custom fields depending on my needs.

    It’s going fairly well and I’m almost done, however I’m unclear on how meta attributes are supposed to work with the Rest API.

    Here’s what I’ve done so far:

    • Created a custom post type with a Rest API endpoint
    • Created a custom block that saves data to my ‘meta’ field

    My custom data is now shown inside the ‘meta’ object in my Rest API like this:

    meta: {
 paletteData: [
  "#f6f9f4",
  "#2294c5",
  "#323333",
  "#131415",
  "#a3001d"
 ]
}

    However I’d rather not put all my custom data inside meta as that might look a bit messy. Which is why I then used register_rest_field to display the above data. outside of meta.

    Unfortunately now my data is shown in two different objects, and if I try to hide my meta object, neither my custom Rest field nor my editor block will work.

    So here’s my questions:

    • should I be saving my custom data inside meta or should I do something else to save it?
    • Is there any way I can show my custom data inside palette: {} rather than meta: {palette: {}}?

    You can see an example of my live Rest API here if that helps.

    I’ve also uploaded a plugin of my code to github. The plugin adds:

    • A custom post type
    • A rest api endpoint at /wp-json/wp/v2/featuredsites/
    • A block called Palette Meta Block which allows to pick a colors which are saved within meta: { palette: {}}.
    • a rest field which prints the palette custom field data inside palette:{}

    You should be able to use it to test how my code works.
    (PS the block doesn’t work great, I’m still working on it.)

    Sorry in advance for the messy code, the plan was to clean it up once it was fully done.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Moderator bcworkz

    (@bcworkz)

    If you are saving your data in the postmeta table, then using the API’s meta functionality makes the most sense IMO. The only alternative would be saving data in a custom table. If you did that you’d need your own REST API handlers. Personally, if a separate table were warranted, I’d likely not use the API to access it. It’d be easier to develop a custom interface through admin-post.php or admin-ajax.php.

    I don’t see any reason to move your meta data out of the response’s meta key. Yes, maybe the data structure is more elegant, but no one sees it. The app handling the response doesn’t care about aesthetics. I wouldn’t recommend doing so. The more you deviate from the standard schema, the less useful it becomes.

    Thread Starter creativiii

    (@creativiii)

    Fair enough, my main reason not to create a custom interface was wanting to work with the React Gutenberg editor as I really like its functionality.

    Are there any good resources you could recommend on creating a custom admin-post.php interface?

    Moderator bcworkz

    (@bcworkz)

    Sadly admin-post.php isn’t well documented. It’s too bad because it’s a great way to implement custom code. You could look through this article. At first it sounds like it’s advocating wp-load.php, but keep reading, it really isn’t. The article’s goal is to load a dynamic CSS file, but once admin-post.php calls your action callback, your code can do whatever you want it to (within the limits of PHP).

    Your React code could request admin-post.php just as it could request the API. AFAIK there are no WP helper functions to do so though, it would be via a generic HTTP request. Come to think of it, admin-post.php is intended to be used to send a new page to the browser. I think it may make more sense for you to go through admin-ajax.php instead, where the response is intended to be used by script instead of loading a new page. Usage is very similar. Ajax is better documented. Be forewarned the example Ajax code has some errors where debugging is needed for it to actually work. The examples are meant to be illustrative, not functional, so I’m told.

    Either admin-????.php file can be made to work. Either of them could be seen as a bit hacky in the context of the block editor and the REST API. The main reason for doing so is because IMO it’s easier to make use of custom tables that way. It would be much more elegant to extend the API to make the custom tables accessible, but more work as well.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Custom field data and custom Rest API fields’ is closed to new replies.