Support

Account

Register Login

Forum Replies Created

  • I just noticed this on the register_block_type() page:

    acf_register_block_type( $settings );

    $settings

    (array) (Required) Array of arguments for registering a block type. Any argument from the JavaScript registerBlockType() function may also be used.

    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.

  • I believe Bill Erickson has some tutorials about retrieving block data. (Pause to look.) Yes! At the bottom of this article, he explains how to use parse_blocks on ACF blocks.

  • 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?)

  • Yes, you need to create an archive-whatever.php file and then a custom loop with the ACF fields in it.

  • I think we might need a little more information: what type of fields, where/how are you trying to display them, and what have you tried so far?

  • 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.

Viewing 9 posts - 1 through 9 (of 9 total)