As you can see, it has automatically used the title of this post for its content. Now, let’s look at the same block in a different context: <\/p>\n\n\n\n
To get access to post meta in the post editor, their are a few prerequisites before actually working on the block. Firstly, if you are developing a block for a custom post type, both the post type and any meta you would like access to in the editor must be published and accessible in the WordPress REST API. To accomplish this, ensure your custom post type supports custom fields, and ensure you set the show_in_rest<\/em> arg to true in your call to register_post_type<\/a><\/em>:<\/p>\n\n\n\n
register_post_type('POST_TYPE_NAME', array(\n    ...\n    'supports' => array('custom-fields', ...),    \/\/show the post type's meta in the WordPress REST API \n\n    'show_in_rest' => true,    \/\/show the post type in the WordPress REST API\n    ...\n\n\n));<\/code><\/pre>\n\n\n\nThis will allow the editor to use the WordPress REST API to get data about the custom post type.  Then, when registering post meta, set an identical arg when calling the register_post_meta<\/em><\/a> function:<\/p>\n\n\n\n
register_post_meta('POST_TYPE_NAME', 'POST_META_NAME', array(\n    'show_in_rest' => true,    \/\/show this post meta in the WordPress REST API\n\n    ...\n));<\/code><\/pre>\n\n\n\nNow, the post type and meta attributes will appear in the API. Next, we need to add support for context-based data to our block. To do this, modify the block’s block.json<\/em> file like so:<\/p>\n\n\n\n{\n\n    \"usesContext\": [ \"postType\", \"postId\" ],\n    ...\n\n}<\/code><\/pre>\n\n\n\nThis will provide the block content in the block editor with the post type and the post id of the post referred to in the block’s context. To make use of this data, use the object passed in to the edit function in edit.js<\/em>, props.context<\/em>.<\/p>\n\n\n\nexport default function Edit(props) {\n    console.log(props.context.postType)\n    console.log(props.context.postId)\n}<\/code><\/pre>\n\n\n\nThis will log the post type and the post id of the post in context.  We can use these two pieces of context data to access other pieces of post data using WordPress’ useSelect<\/a><\/em> hook.<\/p>\n\n\n\n
import { useSelect } from '@wordpress\/data';<\/code><\/pre>\n\n\n\nThis hook allows the retrieval of props from registered selectors.  Use it like this:<\/p>\n\n\n\nconst post_meta = useSelect((select) => {\n    const { getEditedEntityRecord } = select('core');\n    const record = getEditedEntityRecord('postType', props.context.postType, props.context.postId);\n    return record.meta;\n})<\/code><\/pre>\n\n\n\nThis code uses the getEditedEntityRecord<\/a><\/em> function to retrieve a record about a particular post.  We specify an attribute to get the post by, in this case, postType<\/em>, and then we supply the post type and post id from the context. This data includes the post title, author id, post meta, and more. This particular call is concerned with the post meta. By returning the record’s meta attribute, we get access to a JavaScript object containing all the post meta attributes, which we can then use to add post-specific data to the block’s editor-side contents. This object can be used to output the content of post meta in the editor.<\/p>\n\n\n\n
Why is this so important? In the WordPress block editor, a paradigm that developers are supposed to uphold is the WYSIWYG principle. This means, “What You See Is What You Get”, and what that means is that what you see in the block editor should look exactly the same as the output will look on the frontend of the site. <\/p>\n\n\n\n
This means that the actual values of post meta and other post attributes need to be outputted within the block editor, because these are the values that will be outputted on the frontend. So, now that we know how to get access to this data in the block editor, let’s move on to part two: getting the post metadata on the frontend of the site.<\/p>\n\n\n\n
<\/figure>\n\n\n\nOn the frontend<\/h2>\n\n\n\nThere are a couple ways to determine a block’s output on the frontend of a WordPress site. One of these is using the save.js<\/em> file. This file is written very similarly to the edit.js<\/em> file, and, in fact, all post metadata can be gotten in the exact same way, using the method previously described for the edit.js<\/em> file.  So simply repeat the code from the previous section in the save.js<\/em> file if you decide to use it to generate your frontend content.<\/p>\n\n\n\n
The other method of outputting block content on the frontend is using the render.php<\/em> file.  This file uses php to dynamically generate a whenever a visitor visits the site.  Fortunately, since this file is written in php, we can use all the handy built-in functionality that WordPress provides to grant us access to the post data in the current context.  <\/p>\n\n\n\n
One way to get access to post data from the context post is by using the global $post<\/em> object.  Here is an example of checking the post type, and getting some of the post meta using this object:<\/p>\n\n\n\n<?php\nglobal $post;\nif ($post->post_type != 'page'){\n    echo get_post_meta($post->ID, 'META_KEY', true);\n}\n?>\n<\/code><\/pre>\n\n\n\nThis code uses the global $post<\/em> object, which is automatically defined and updated by WordPress, to check the current post type. If it is a page, it echoes out the “META_KEY” meta attribute to the page, causing it to appear when a user visits this page.<\/p>\n\n\n\nWordPress also provides utility functions, such as get_the_title()<\/a><\/em>, get_the_content()<\/a><\/em>, get_the_author()<\/em><\/a>, and get_the_ID()<\/a><\/em>.  These are wrappers that use the global $post<\/em> object under the hood.  It is generally recommended to use these instead of accessing the global object directly.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\nIn summary, we began by learning about the concept of context<\/em> in the, well, context of WordPress Block Development.  Context determines which post record in the database WordPress will pull data from when generating a block.  The example of the Post Title block was used to show how the same block in the same post can show different content based on the context it is placed in.  When in the post body, it showed this post’s title, but when contained within a query loop, it showed the title of the article dictated in the loop.<\/p>\n\n\n\n
Then, we turned our attention to how we could replicate this functionality of the Post Title block within our own custom blocks. The method for getting context post data in the block editor used the usesContext<\/em> attribute of the block.json<\/em> file along with the useSelect<\/em> hook to get post data from the REST API. Meanwhile, on the frontend, the php helper functions can be used to get post attributes when rendering blocks to the frontend.<\/p>\n\n\n\nConclusion<\/h2>\n\n\n\nSo now, you know how to develop your own WordPress blocks with context-based access to post metadata. I wrote this guide because I searched for hours upon hours for how to do this in my own project, and found nothing! So, I hope this guide has proven useful to you and helped you in your block development endeavours!<\/p>\n\n\n\nClick to read more about my other WordPress Development ventures<\/a>!<\/p>\n","protected":false},"excerpt":{"rendered":"
One of the unique and interesting challenges that arises when developing new block types for WordPress sites is getting access to post-specific data from the database in your block. Access to this data is needed both on the user-facing frontend, where visitors will see your posts, and on the editor backend, where post authors write […]<\/p>\n","protected":false},"author":1,"featured_media":303,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[29,34,24,16,33,32,30,17,18,31],"class_list":["post-280","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress-development","tag-block-dev","tag-custom-block","tag-javascript","tag-php","tag-plugin","tag-plugin-dev","tag-react","tag-web-dev","tag-wordpress","tag-wordpress-dev"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/jacob-t-graham.com\/wp-json\/wp\/v2\/posts\/280","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jacob-t-graham.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jacob-t-graham.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jacob-t-graham.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/jacob-t-graham.com\/wp-json\/wp\/v2\/comments?post=280"}],"version-history":[{"count":18,"href":"https:\/\/jacob-t-graham.com\/wp-json\/wp\/v2\/posts\/280\/revisions"}],"predecessor-version":[{"id":931,"href":"https:\/\/jacob-t-graham.com\/wp-json\/wp\/v2\/posts\/280\/revisions\/931"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/jacob-t-graham.com\/wp-json\/wp\/v2\/media\/303"}],"wp:attachment":[{"href":"https:\/\/jacob-t-graham.com\/wp-json\/wp\/v2\/media?parent=280"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jacob-t-graham.com\/wp-json\/wp\/v2\/categories?post=280"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jacob-t-graham.com\/wp-json\/wp\/v2\/tags?post=280"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}