I just noticed this on the
acf_register_block_type( $settings );
So if you normally add your props in
registerBlockType(), you should be able to add them when you register the ACF block.
However, as a person with very limited JS experience, I just add any additional classes in the block template code.
Pretty sure that’s a Gutenberg problem and not an ACF problem. The block editor wants to put EVERYTHING in that tiny sidebar on the right.
If you create an ACF block and assign the field group to the block, you will at least be able to fill out the fields within the block. If the fields are for a CPT, you can add that block to a block template for the CPT, so that it’s there automatically when you create a new CPT post.
There may be a way to force the field metaboxes to show up below the edit screen, but I’m not aware of it.
Welcome to the block editor, Danny. Most metaboxes show up in that tiny right-hand sidebar, and very awkward it is. (Plus there are some that won’t show up at all…)
I would recommend that you follow the instructions to create an ACF block and assign your field group to that block. You can limit the block to the specific post type, and create a block template so that block is right there in the editor when a new CPT post is created.
Though the fun part is going back and converting over any older posts…
I think we are discovering the difference between when we want to use a metabox and when we want to use a block. One of the values of having something stored in
postmeta is being able to retrieve it from elsewhere. I’d been hoping for something similar to the way we retrieve field values from options pages, but that doesn’t seem to work. It’s making me re-evaluate my original ideas about converting field groups to blocks. Though I bet it wouldn’t be that hard to create a block that inserted the output from a field group, even though we might not be able to do that with ACF. (Too recursive?)
You might consider parent and child post types (see http://justintadlock.com/archives/2013/10/07/post-relationships-parent-to-child for a bit about this). You can see examples of this kind of thing in the Sensei learning management plugin, which has a Course post type with other post types as children: lessons, quizzes, etc. You’ll probably want to explore different possibilities.
I would not worry too much about the URL structure–just don’t alter it to the point that WordPress gets confused. If you make major changes to the site you will end up needing to create 301 redirects anyway, and you can use regular expressions to make your life easier there.
Here is the reason you need custom post types–not always, but sometimes.
It’s MUCH easier to display content from custom post types elsewhere on your site (that is, not on the page where you entered the content) than it is to display custom fields elsewhere.
I discovered this the hard way: I set up a repeater field group for “Careers” information. The field names were “job title”, “job description”, and “info link.”
Displaying three sets of these on the original page–no problem. I followed the instructions for looping through repeater fields and it worked fine.
But I wanted to be able to display JUST the custom field content elsewhere on the site. After EXTENSIVE trial and error (I’m not that great a developer), I was able to create a page template that looped through all the posts that had career fields and displayed just the field info.
The problem was that I wanted to sort by job title, not by post, and there were three careers per post. It may be possible to do this with ACF, but according to my Real Developer husband, it would be hugely resource-intensive to do so.
So instead, I created a Career custom post type with ONE custom field (for the info link) and PRESTO! It was extremely easy to create an archive page for Careers that listed careers alphabetically. It was also easy to create a post page template to show 3 career entries with the same taxonomy as the post. AND I can easily display careers in widgets. (It’s a Genesis theme.)
So that’s really why you need custom post types (which may have ACF fields in them): when you have to be able to display the content in different ways in many places in your theme.
For me, at least, rolling a custom post type and taxonomy is a heck of a lot easier than working out ways to display fields, too. WordPress just doesn’t support field retrieval in the same ways as post content retrieval. ACF helps make it easier, but is still limited by the fact that all your ACF data goes into the post_meta table.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
© 2022 Advanced Custom Fields.